home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001325_daemon _Wed Jun 16 16:53:30 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA18895; Wed, 16 Jun 93 16:53:32 MET DST
  3. Return-Path: <mvanheyn@cs.indiana.edu>
  4. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  5.     id AA18891; Wed, 16 Jun 93 16:53:30 MET DST
  6. Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  7.     id AA28345; Wed, 16 Jun 1993 17:15:40 +0200
  8. Received: from localhost by moose.cs.indiana.edu
  9.     (5.65c/9.4jsm) id AA08302; Wed, 16 Jun 1993 10:15:36 -0500
  10. From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
  11. To: www-talk@nxoc01.cern.ch
  12. Subject: Re: Resource estimation 
  13. In-Reply-To: Your message of "Wed, 16 Jun 1993 10:04:22 +0200."
  14.              <9306160804.AA03888@www3.cern.ch> 
  15. Date: Wed, 16 Jun 1993 10:15:36 -0500
  16. Message-Id: <8299.740243736@moose.cs.indiana.edu>
  17. Sender: mvanheyn@cs.indiana.edu
  18.  
  19. Thus wrote: Tim Berners-Lee
  20. >>From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz>
  21. >>For my proposal that's going to the committee here (I'm soon going  
  22. >to
  23. >>make all my CWIS documents available for public review via our WWW
  24. >>server -- I wrote them in HTML so it shouldn't be too hard to serve
  25. >>them :-) I need some estimates of the hardware to run a dedicated  
  26. >WWW
  27. >>server off.
  28. >
  29. >In fact, the load on an HTTP server machine is very slight,
  30. >because the process only runs as long as it takes to return
  31. >the document. The info.cern.ch server which has the Subject
  32. >Catalogue gets probably a relatively high usage, about
  33. >10k requests a day, or (thinks...) one every 9 seconds.
  34. >the CPU load is negligible.  In fact of course the peak rate
  35. >is higher, but still its not really a factor.
  36.  
  37. This goes along with our experience (though our load is only maybe 40%
  38. of yours.)  Just passing text files along is pretty cheap.
  39.  
  40. Of course, if you're getting to pick the platform, part of it depends
  41. how you'll have the server configured and what kinds of access it will
  42. be doing.  If you are using standard multithreading with lots of
  43. fork()ing then a system with copy-on-write would be nice.  If your
  44. server does lots of execing instead, this won't help as much.  Lots of
  45. physical memory is always nice (lazy man's performance philosophy is
  46. to let the OS do the caching.)  Being able to plock() the server
  47. process so it doesn't get swapped might be good, though if it's as
  48. heavily used as you hope this won't be an issue much.
  49.  
  50. Will people be using this system to just fetch simple HTML files, or
  51. as a gateway, or to do frequent queries of large databases?  I expect
  52. that only in the last of these three is adequate CPU power likely to
  53. enter into the picture.  If you anticipate doing cryptographic
  54. manipulations as part of transactions (e.g. kerberos authentication or
  55. PEM or something like that) obviously that can eat some CPU.
  56.  
  57. - Marc
  58. --
  59. Marc VanHeyningen   mvanheyn@cs.indiana.edu   MIME & RIPEM accepted
  60. "I cannot recommend this candidate too highly or say enough good things about
  61. him.  In my opinion you will be lucky to get him to work for you.  I urge you
  62. to waste no time making him an offer.  No one would be better for the job."